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TO ALL WHOM IT MAY CONCERN: 

BE IT KNOWN that we, Daniel Brown, William Lance Eason, and George A. 
Thompson, residing in the State of Texas, have invented new and useful 
improvements in a 

RULES-BASED NOTIFICATION SYSTEM 

of which the following is a specification: 
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CROSS-REFERENCE TO RELATED APPLICATION 



1 This application claims the benefit of United States Provisional Application 

2 No. 60/158,732, filed October 11, 1999. This application also contains matter in 
\]K <^3 fflmmnn with copending US application Serial No ^. . _. , . filed on even 

0^ 4 date herewith, titled CUSTOMIZABLE USER WINDOW, which is incorporated by 

5 reference. 



BACKGROUND OF THE INVENTION 

Q 

^0 6 1. Field of the Invention: 

yi 

y s 

"E 7 The present invention relates generally to communications for electronic 

|" 8 computer systems, and more specifically to a system and method for notifying a 

h 9 user that selected events have occurred within the system. 

Q 

k'""s 

3 10 2. Description of the Prior Art: 



11 As computer systems and data communications become increasingly 

12 widespread, more and more users are able to perform a high percentage of their 

13 daily tasks over various communication networks. For example, many users are 

14 able to obtain key information in a timely manner through the use of interconnected 

15 software and hardware systems. 
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1 Because of the great wealth of information available, it often becomes time 

2 consuming for a user to keep up with items and events of interest. In some cases, 

3 a dedicated window may be included on a user's desktop to provide information 

4 about high priority items. For example, a streaming stock quote ticker may be 

5 resident on a user's desktop to enable them to keep up with selected stock market 

6 information. However, the number and variety of sources of potentially interesting 

7 information is so large that this type of dedicated approach can work for only a 

8 small number of sources. 

0 9 Often, a user is required to access a database or other source of information 
ffl 10 in order to determine whether an event of interest has occurred. This can be 

01 11 relatively time consuming, and often results in undesirable delays if the user is 
p 12 unable to check the required sources often enough. 

S i 

S==3 

j=j 13 Another approach is to automatically send notifications directly from an 

p[ 14 application to a user when selected events occur. This requires coding of the 

^ 15 necessary handling and routing modules within the application. This can become a 

16 significant burden from the application writer's standpoint, and can lead to 

17 inconsistencies in the way message notifications are presented to users. 

18 It would be desirable to provide a system and method for automatically 

19 notifying users upon the occurrence of selected events. It would further be 

20 desirable for such notification system to be able to handle different types of events 

21 and present notifications to users in different ways. 
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SUMMARY OF THE INVENTION 

1 In accordance with the present invention, a system and method for providing 

2 notifications to a user includes an alert manager. The alert manager receives 

3 notifications of events incurring within various executing applications, and utilizes 

4 rules to determine when alert notifications should be sent to one or more specified 

5 users. In addition, operation of batch jobs can determine changes in state of 

6 selected data, which generate events for the alert manager in addition to those 

7 generated directly by an executing application. Alert notifications to users can be 

8 sent to the user via any of several communications channels. 



Q 
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BRIEF DESCRIPTION OF THE DRAWINGS 

1 The novel features believed characteristic of the invention are set forth in the 

2 appended claims. The invention itself however, as well as a preferred mode of use, 

3 further objects and advantages thereof, will best be understood by reference to the 

4 following detailed description of an illustrative embodiment when read in 

5 conjunction with the accompanying drawings, wherein: 



6 Figure 1 is a high-level block diagram of a system in accordance with the 

Q 7 present invention; 

SJ] 

ffs 

ffi 8 Figure 2 is a block diagram indicating additional details of the system of 

£ 9 Figure 1 ; 

5 

5 3_ 

i 

B 10 Figures 3A and 3B illustrate operation of different types of event generation 

2 11 techniques; 

12 Figure 4 shows the type of information maintained by an event router in 

13 accordance with the present invention; 

14 Figure 5 is a block diagram illustrating an operation of an alert manager; 

15 Figure 6A illustrates one preferred embodiment for using a rule filter with 

16 event handlers; and 
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1 Figure 6B illustrates an alternative embodiment for using a rule filter with 

2 event handlers. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

As will be understood by those skilled in the art, the present system and 
method can be used with nearly any computer system in which events occur during 
execution of an application, or in which data is changed. In the preferred 
embodiment, the operating applications are of a type which generate messages 
indicating the occurrence of selected events. However, as described below, the 
system will also work with applications which do not generate such events, and is 
adaptable to nearly any type of computer application. 

Referring to Figure 1 , a preferred embodiment of the inventive system and 
method is illustrated generally as reference number 10. A plurality of applications 
12 operate concurrently, and may be located on a single piece of hardware, or 
spread among numerous machines. The applications 12 need not operate in 
conjunction with one another, but may be a wide variety of selected applications, of 
any type, which perform data processing functions. 

As will be described in more detail in connection with Figure 2, applications 
12 generate events 14, which are forwarded to an event router 16. Events 14 are 
basically messages indicating that some type of predetermined event has occurred. 
As defined further in connection with Figure 2, these messages may be generated 
directly by applications to indicate that an event has occurred in that application. 
For example, an application which is used to change the price of a product in a 
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1 database can generate an event message indicating the product number and new 

2 price for the product. In addition, as described below, certain types of applications 

3 12 may periodically scan persistent information, such as that stored in databases, 

4 to determine whether data has changed. These applications can also generate 

5 events showing that changes of the selected type have occurred. 

6 Event router 16 is described in more detail in connection with Figure 4, but is 

7 generally an application which receives incoming events 14, and routes them to 

8 recipients which have registered to receive events of this type. For example, if a 
G 9 user or another application has registered to receive notification of price change 
ffv 10 events, the event router 16 will maintain this information. When an incoming price 
ffj 11 change event is received by event router 16, it will then be forwarded to all 
J 12 applications which have been registered to receive this event. 



O 



13 Event router 16 therefore acts as a central routing point for messages. It is 

14 not necessary for applications 12 to know, or be able to find out, who will receive 

15 notifications of events. Instead, applications 12 simply generate defined events and 

16 send all of them to event router 1 6. Event router 1 6 handles the task of sending the 

17 events to as many recipients as are registered to receive them. 

18 Some events 18 are routed to various types of event handlers 20, which 

19 then use the incoming event message to process data. In many cases, event 

20 handlers 20 will also be classified as applications 12. In this application, event 
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1 handlers 20 are generally any applications which make some use of the information 

2 provided by incoming event messages 18. 

3 ^^s^Some events 22 are routej/to an alert manager 24, which is a particular type 

4 of event handler. As described further in connection with the remaining figures, 

5 alert manager 24 handles incoming events by determining whether any incoming 

6 event requires that a/notification, or alert 26, to be forwarded to a user 28. Alert 

7 manager 24 utilizes a set of rules to determine to whom, and when, notifications 

8 should be ma^le to a user 28. 



Referring to Figure 2, the types of applications 12 which generate events 
may be classified generally into two categories. The first category is referred to 
herein as business objects 30, which may include within them state machines 32 
and similar operating modules. Business objects 30 generate "explicit" events, 
meaning that the code of the business object application explicitly generates an 
event to be sent to event router 16 as events occur. This capability must be 
programmed into business objects 30 and their state machines 32. 



16 Explicit events are useful, in the present invention, for indicating when a 

17 single event has occurred. For example, when a sale is made, or a product 

18 changes price, or a new product becomes available, if the corresponding business 

19 objects are properly programmed events will be generated. These can be picked 

20 up by alert manager 24, and used to generate notifications. 



Patent Application.doc/40014 



Page 9 




1 A second kind of application that can generate events is referred to herein 

2 generally as "batch jobs." These jobs are applications that, generally, periodically 

3 check persistent data, such as data stored in a database, and look for changes that 

4 ifiay have occurred. For example, if an application which enters new products into 

5 a database is not one which has previously been coded as a business object, to 

6 generate explicit events on this occurrence, a batch job 34 can periodically scan a 

7 product database and determine when new products have been added. Events 

8 which are discovered by such a comparison between a previous state of an object, 

9 in a persistent memory, with the current state are referred to herein as "implicit 
O io events." 

.sr. 

*y . 

^ 1 1 Use of batch jobs to scan data looking for implicit events is useful both for 

J 12 events which occur over time, and for use with applications which are not already 

|L 13 coded to generate the desired explicit events. 

Is* 

b 

q 14 Event router 16 can route events to two different types of handlers. These 

o 

~ 15 can be categorized generally as synchronous handlers 36 and asynchronous 

16 handlers 38. Events which are intended for use by asynchronous handlers are 

17 preferably placed into a queue 40, from which they are later withdrawn by various 

18 asynchronous handlers 38. More than one queue 40 can be provided, and 

19 registration of a handler with the event router, to be notified of a particular type of 

20 event, will indicate whether the handler is synchronous, or asynchronous, and in 

21 the later case indicate which queue is used for the event message. 
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implicit events. In Figure 3A, dataflow occurring upon an explicit event is shown. In 
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this example, a user running an application enters a new product, number 789, and 
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identified as a BOAT , into the system. 
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business object 44, an event 46 is generated and sent to event router 16. Event 46 
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in Figure 3A. However, business object 50 is one which does not generate an 
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explicit event message when the data base is updated. Thus, no message is sent 
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to event router 1 6 at 9:08. 



Patent Application.doc/40014 Page 1 1 




1 At 10:00, in this example, the batch job executes again. At this time, the 

2 information it collects is shown in table 52 and includes three products. By 

3 comparing the present table 52 with earlier table 48, the batch job determines that a 

4 new product has been added to the data base. The batch job then generates an 

5 implicit event showing that the new product has been added, and sends it to router 

6 16. 



7 Depending upon the implementation, it may be desirable for implicit events 

8 to carry a flag distinguishing them from explicit events to assist either the router or 

9 handler in determining how to treat the message. However, in other cases, it may 

10 not be necessary to distinguish between implicit and explicit events; only the fact 

1 1 that an event occurs would be of interest to the handlers. 



12 Figure 4 indicates the type of information retained by event router 1 6 in order 

13 to route events which it receives. The information is shown in Figure 4 as a table, 

14 but may be stored internally within event router 1 6 in any desirable form. 

^Referring to Figure 4, the'teble indicates that event router 16 stores a list of 

Iff types of events which are to be routed. This table is preferably dynamic, and can 

17 be added to as variou^riandlers register with event router 16. In the example of 

18 Figure 4, EVENTyrYPE 1 has three recipients, R1, R2 and R3, registered to 

19 receive a copy/of this type of event. Thus, when an event of EVENT TYPE 1 is 

20 received by/event router 16, recipients R1, R2 and R3 in turn receive a copy of the 

21 event message. Identification of the recipient indicates where the message will be 
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1 sent, and any other particular conditions under which ifshould be forwarded. If any 

2 recipients R1, R2 or R3 are synchronous handlers, the event message will be 

3 copied and forwarded to them immediately; If any of these recipients are 

4 synchronous events, the registration of s\m\ event will indicate a queue into which 

5 a copy of the event message should braced. 

6 Figure 4 shows five different event types, with various recipients registered 

7 to receive them. Some event types, such as EVENT TYPE 3 in this case, may not 

8 have any registered recipients. In such case, any events of this type are not routed 

9 to a handler. In most cases, however, one or more recipients will be registered to 

10 receive an event, and event router 16 will forward copies of the event message to 

1 1 all registered recipients. 



12 By use of the event router, recipients can register to receive messages of 

fL 13 various types without having any impact on the business objects which generate 

ess. 

Q 14 these events. Instead, the events are consistently passed to event router 16, from 

£=!»■ 
j j 

15 • which any handler which needs to be copied on the event message receives its 

16 forwarded copy. Each handler will then deal with a message according to its 

17 internal logic. 

18 Figure 5 is a block diagram illustrating functioning of the alert manager 24. 

19 As described above, alert manager 24 is preferably an asynchronous handler and 

20 therefore receives its events from a queue. 
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1 Within alert manager 24 are two major portions. These include a rules 

2 portion 60, and a notifications portion 62. Rules portions 60 contains a large 

3 number of rules defining when events are to be acted upon. Each user who 

4 desires to receive alert notifications from alert manager 24 will register with the alert 

5 manager, and define the conditions under which that user wishes to receive a 

6 notification. Rules are generally conditional statements which define where the 

7 notification is to be generated. 




yn the example show in Figure 5^wo rules are provided. The conditional for 
O 9 the first rule provides that a product equals ("BOAT'), and a price less than 



10 $7,500.00. If an event occurs which makes this conditional TRUE, a corresponding 



1 1 notification 62 will be^enerated to the user requesting this alert. 

12 In this example, a price-change event 64 is passed to alert manager 24 by 

13 its associated queue, the rules portion 60 compares the context data passed along 

14 with the message with its rule conditional portions. The comparisons are performed 

15 by a rules engine 66, which receives rules and context data from rules portion 62 

16 and returns Boolean values of true or false depending upon the evaluation of the 

17 conditional. In this example, rules engine 66 returns a value of TRUE for the first 

18 rule, because the product is "BOAT' and the price is less than $7,500.00. 

19 When the condition of a rule is satisfied, the corresponding notification is 

20 then executed and sent to the user 28. Notifications can involve sending a 

21 message by a computer communications network to a user's desktop. Notifications 
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can also include sending of a message via phone, pager, fax, or any other desired 
technique. The contents of the message are defined by the notification portion of 
the rule. Preferably, a fairly large number of preselected message types will be 
available, so that a user will be able to select from these messages. The messages 
can include textual information, and can include as parameters some or all of the 
context information included with event 64. In the example of Figure 5, an e-mail 
message can be sent to the user who registered Rule 1 indicating that a price 
change for BOAT has occurred, and indicating the new price for the BOAT. A call 
can be. made to a pager at the same time; any desired number of notifications can 
be made. 

This rule base system allows users to register with the alert manager 24, 
defining logical conditions under which alerts of various types will be sent. This 
frees the user from having to check for events or changed conditions individually; 
this is done automatically by the rules set up in the alert manager. Users can 
determine how these messages are to be sent. E-mail would be one typical type of 
message; users may also provide for one or more notification windows to be 
generated upon their desktop for the sole purpose of receiving alert notifications. 

By setting up and registering different types of alerts with a central system, a 
user can be notified regarding a wide variety of events which would otherwise take 
too much time and effort to profitably be viewed. Upon receiving one of these 
alerts, the user can, if she so desires, take a corresponding action. 
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The method described above can bp generalized and modified to provide 
different functionality. Referring to Figure 6A, a diagram is shown of a system 
which uses a rule filter similar to the m\es portion of an alert manager 24 for event 
handlers in general. When business object 30 generates an event 14, it is 
communicated to event router to. Event router 16 then sends copies of event 70, 
72 to event handlers 74 and/76 which have been previously registered with event 
router 16. Event handleraf74, 76 each have a rule filter 78, 80, respectively, which 
uses conditionals in essentially the same manner as described in connection with 
Figure 5. These rule filters allow for initial filtering of events by event handler 74, 76 
as part of the determination of which events to respond to. 



■^^AAn alternative approach is shown/fn Figure 6B, in which a combined 
router/filter includes event router 16 and/rule filter 84. When business object 30 
sends an event 14 to event router 16/ rule filter 84 is checked to see whether any 
rules apply to such event. If a conditional of a rule is met, the functional portion of 
the rule, directing events to particular handlers, is then executed. For example, 
when event 14 is sent to /event router 16, the corresponding copy is not 
automatically sent to both epent handlers 86, 88. Instead, the context data included 
with event 14 is evaluated as described in connection with Figure 5 within rule filter 
84, and events are onfly sent to handlers for which the rule conditional evaluates 
true. In this example, event copy 90 is forwarded only to event handler 88 because 
no corresponding conditional was satisfied which would cause event 14 to be 
routed to even/handler 86. 
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1 Inclusion of rule filter 84 with event handler 16 allows for several changes in 

2 the system. Initially, router/filter 82 must be more complicated, and allow handlers 

3 to register rules with filter 84 as well as simply being added to a list in event router 

4 16. Preferably, rules in filter 84 are checked only for handlers which are registered 

5 for a particular event type, so that only a few rules need to be checked when an 

6 incoming event is received. 

7 Inclusion of rule filter 84 with event router 16 increases the complexity of the 

8 code associated with the event router, but decreases communications to event 
Q 9 handlers. Only events which satisfy a predefined criteria are passed to an event 
jjp 10 handler by rule filter 84. In addition to lessening network traffic, this approach 
J 11 simplifies all of the event handlers. Each event handler may be simplified by 
01 12 deleting any initial rule filter used to handle incoming events; instead, this filtering is 

s 

M= 13 performed by rules registered with rule filter 84. 

U 
y. 

O 

□ 14 The system and method described above provide a simplified method for 

□ 

15 generating user alerts in response to various events taking place within 

16 applications. By sending all events to a central location, an alert manager can 

17 register for any desired type of event and, in response to logical conditionals being 

18 satisfied, send alert notifications to any registered users. Because the system can 

19 handle both explicit and implicit events, it is suitable for use with existing 

20 applications which do not generate events suitable for routing through event router 

21 1 6, or which do not generate events of interest to a particular user. 



Patent Application.doc/40014 



Page 17 



1 Users gain the ability to select types of events for which they wish to be 

2 notified. When these events occur, notification occurs automatically. The user 

3 need not periodically review various locations to determine whether anything has 

4 happened. Users can select from among types of events, and the applications 

5 writers can determine which events to actually make available. For example, a 

6 user can register with the alert manager 24 to be notified whenever a new product 

7 is introduced by a competitor; automatic notifications will be provided whenever this 

8 occurs, assuming the events are available as either explicit or implicit events. 

9 Preferably, users will be able to select from one or more menus of choices 
10 provided by the system. This simplifies the task of registering to receive alerts, and 

ofi 11 ensures a certain uniformity of notifications across all users. The conditionals used 

12 in the alert rules can be provided as templates, with the user selecting the form of 

13 the conditional and any particular values to be used. In this manner, the user can 

14 ' easily provide a set of alert rules to meet his or her needs. 



i 

14 




15 ^jvi^Vs described previously, the alert [notifications themselves can be provided 

16 in any available format supported by fae system. Notification may be by e-mail or 

17 other electronic messaging as known in the art. By sending appropriate messages 

18 to any type of intermediate ipfterface devices, messages such as pages or 

19 telephone alerts can also be jriade. Because the alert notification message and its 

20 type are maintained in tables in the alert manager, addition of a new technology is 

21 easily made to the alect system. All that is necessary is to provide that a selected 

22 message be sent p an appropriate handler form the alert manager, and the 

23 message can beysent to the registered user. 
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1 While the invention has been particularly shown and described with 

2 reference to a preferred embodiment, it will be understood by those skilled in the art 

3 that various changes in form and detail may be made therein without departing from 

4 the spirit and scope of the invention. 
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